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The use of a single application data table to provide 
infbrmatioh across all services within a bouquet pro- 
vides a number of advantages, in particular when decid- 
ing whether or not to maintain-certain applications when 
switching between services. 
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Description 

[0001 ] The present invention relates to a digital trans- 
mission system, in particular a digital television system. 
[0002] Existing digital television systems transmit data 
in the form of discrete transport stream packets or trans- 
port packets, each packet being of a predetermined 
length and containing a header and a payload. The 
MPEG-2 standard is the currently favoured standard in 
this domain and sets out a predetermined format for 
such packets. 

[0003] The packet header comprises general descrip- 
tive data regarding the packet, whilst the payload com- 
prises the data to be processed at the receiver. The 
packet header includes at least a packet ID or PlD iden- 
tifying the packet. The payload of the packet may con- 
tain audio, video or other data such as conditional 
access system data or, in particular, application data 
used toy the decoder to set up interactive or other appli- 
cations. Data within a PlD packet may further be divided 
into a number of tables or sections, identified by a table 
ID or TID value and. in a yet further precision, a TID 
extension value. 

[0004] Data in a conventional transport stream is 
organised as follows. At the highest level, a programme 
access table or PAT table lists the PlD values of one or 
more programme map tables or PMT tables, each PMT 
table being associated with a sen^tee within the trans- 
port stream. The PMT table in turn refers to the PlD val- 
ues of the packets containing the audio data, video 
data, application data etc. for that service. As will be 
understood, whilst a service may be considered as cor- 
responding loosely to a television channel, the concept 
of a service is somewhat broader, since a service may 
contain multiple audio and/or visual data streams, only 
application data etc. 

[0005] Conventionally, each senrk^e operates more or 
less independently and contains all applk»tions needed 
by that service. This may include applications specifi- 
cally linked to the programme being broadcast on that 
service (for example, a foolt>all application associated 
with a match shown on that channel) as well as more 
general applications, such as start-up applications or 
the like. The former type of applications may be 
accessed via only one or a small nunt)er of services, 
whilst the latter may be canied on aH servk;es. 
[0006] Information regarding the applications carried 
on a service, including the version number of the appli- 
<;ation, the memory space required by an application 
etc.. is usually included in the PMT table at the entry 
point of the service. 

[0007] A particular problem arises with this conven- 
tfonal organisation of data when changing between 
servfoes. As desaibed above, each servK;e contains all 
applications required by that service together with a 
table of information regarding these applications. Upon 
selection of a service, a conventionally configured 
decoder is obliged to download the PMT table and eval- 



uate the content of this table before taking any decision 
regarding cunrently running applk»tions. In view of the 
time normally required to download and analyse a PMT 
table this may prove a cunijersome operation. Further- 
5 more, the flexibility of operation of the decoder is con- 
siderably limited with regard to evaluation of application 
priority etc. 

[0008] It is an object of the present invention, in its 
broadest and/or specific realisations, to provide a sdu- 

10 tion to this problem. 

[0009] According to the present Invention, there is pro- 
vided a method of transmission of application data in a 
plurality of services in a digital transport stream charac- 
terised in provWing an application data table containing 

75 information regarding the apprication or applications 
carried by each of a plurality of services within the trans- 
port stream. 

[0010] The use of a single table "ADT* containing 
information regarding application data across a plurality 
so of services enak>les a decoder to define its operation in 
relation to such applications according to a number of 
different factors. 

[0011] For example, in the case of an appPication 
uniquely carried by one service, a decoder may decide. 

25 based on the information regarding this applk;ation con- 
tained in the applk»tion data table to maintain the appli- 
cation even when switching to a service not containing 
this applk:ation. The sort of infomiation that may be 
used in such an evaluation will be described in more 

30 detail below. 

[0012] The application data table may be advanta- 
geously transported in a transport packet having a pre- 
determined packet ID or PlD value associated with the 
presence of an application data table within the packet 

35 [001 3] Use of a fixed value PlD table to carry the data 
enables all decoders to k>e preprogrammed to qurckly 
tocate and download this table, before accessing any 
service. As will be understood, the appltoation data 
table may nevertheless be connmunicated to or intro- 

40 duced in the decoder by other means, for example, via 
a modem linK smart card etc. Similarly, the ADT talDle 
may also be accessed by PlD references in other tables, 
such as the PMT tables of the«ervk>es in question. 
[0014] Typically, one commercial operator is usually 

45 responsible for the content of a plurality of servfoe chan- 
nels, these channels being grouped together as a bou- 
quet of services. A given transport stream often 
contains a number of bouquets of services each man- 
aged by a different operator. Whilst each operator is 

so fully informed of the applications provided over the serv- 
ices within his bouquet, this information is for obvious 
reasons not usually available to other operators. 
[0015] Preferably, therefore, the method may further 
comprise provkjing a plurality of application data tables, 

55 each application data table containing information 
regarding applications contained within a bouquet of 
services. 

[0016] In an alternative realisation, the aeation of a 
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**8uper'* ADT table providing information on applications 
across a number of bouquets may be envisaged. How- 
ever, In view of the problems In communicating Informa- 
tion between operators, this solution may be difficult to 
put into practice. 

[0017] In the embodiment using a number of applica- 
tion data tables, each application data table may be 
conveniently transported In a table or section within a 
transport packet, each application data table being 
associated with a table or section having a characteris- 
tic table ID or. preferably, table ID extension value. 
[0018] In the case where a number of ADT tables are 
carried within the transport stream this provides a par- 
ticularly convenient way for a decoder to identify the 
ADT table associated with the bouquet of services to 
which the user is subscribed. The TID extension value 
may be contained, for exanple, in the Information com- 
municated to the decoder by the subsaijation card asso- 
ciated with the bouquet in question. AHernatively. the 
decoder may maintain a table of TID extension values 
associated with the various bouquet of services that 
may be received by the decoder. 
[0019] In a preferred optional embodiment, the or 
each application data table Is electronically signed so as 
to permit a decoder to verify an application data table as 
originating from a known operator. Authentiflcatlon or 
signature of data in this manner can be carried out by 
any known method, for example, by a combined hash 
and public keyyprlvate key algorithm to provide an elec- 
tronic signature. 

[0020] In a further preferred embodiment, each serv- 
ice further comprises a programme map table or PMT 
table giving access to applications carried by this serv- 
ice, the programme map table itself conprising informa- 
tion regarding the or each applk»ti6n carried by this 
service. 

[0021] For example. In an embodiment where data for 
an application Is carried within a data carousel 
accessed via a service, the PMT may include informa- 
tion regarding the carousel address of nxxlules of the 
application, 

[0022] In a particularly preferred embodiment, the 
application data table further comprises Informatfon 
regarding which applications may be carried in each 
service, for exanrple in the form of a list of servfoes with 
the applications that may be accessed at any time via 
each service. This list will normally be dynamic and will 
change according to the applications currently referred 
to by a service. 

[0023] In one emtxxjiment, the application information 
earned in the application data table further includes 
information relating to the size of memory required to 
execute an application. 

[0024] Additfonal information may Include a priority 
value indicating the relative priority of an application, a 
service exclusive value Indicating that an application is 
exclusive to one or more services, a flag value concern- 
ing tiie action to be taken with an application upon a 



change of service, a data carousel ID value association 
with the application etc. For further information regard- 
ing data that may be carried in the ADT table, the reader 
is referred to the description of tiie prefened emixxli- 
5 ment. 

[0025] As will be understood, this list is by no means 
exhaustive and any number of other factors may be 
used as well as or instead of those listed. 
[0026] Preferably, the digital transmission system 

10 comprises a digital television system, in particular 
adapted to function according to the MPEG standard. 
[0027] The invention has been described atDOve in 
relation to a method of transmission of digital data. The 
invention further extends to an apparatus for use in such 

IS a method and adapted to transmit a transport stream 
comprising a plurality of services together with an appli- 
cation data table containing information regarding appli- 
cations canrled by a plurality of the services within the 
transport stream. 

20 [0028] The invention further extends to a decoder for 
use in such a method including an application data tatrie 
stored in the memory of the decoder and comprising 
information regarding applications carried by a plurality 
of services within the transport stream, the decoder fur- 

26 ther being adapted to comrol the downloading and/or 
maintenance of such applications in dependence on the 
information contained within the applk»tion data table. 
[0029] As used herein, the term "digital transmission 
system" includes any transmission system for transmit- 

30 ting or broadcasting for example primarily audiovisual or 
multimedia digital data. Whilst the present invention is 
particularly applicable to a broadcast digital television 
system, the invention may also be applicable to a fixed 
telecommunrcations network for multimedia internet 

35 applications, to a closed circuit television system, and 
soon. 

[0030] As used herein, the term "digital television sys- 
tem" includes tor example any satellite, ten^estrial. cable 
or other system. 

40 [0031] The term "receiver/decoder" or "decoder" used 
herein may connote a receiver for receiving either 
encoded or non -encoded signals, for example, televi- 
sion and/or radio signals, which may be broadcast or 
transmitted by some other means. The term may also 

45 connote a decoder for decoding received signals. 
Embodiments of such receiver/decoders may include a 
decoder Integral with the receiver for decoding tiie 
received signals, for example, in a "set-top box", a 
decoder functioning in combination with a physically 

50 separate receiver, a decoder including additional func- 
tions, such as a web browser, or a decoder integrated 
with otiier devices such as a video recorder or a televi- 
sion. 

[0032] The term MPEG refers to the data transmissfon 
55 standards developed by ttie Internatfonal Standards 
Organisation working group "Motion Pictures Expert 
Group" and in particular but not exclusively the MPEG- 
2 standard developed for digital television applications 
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and set out in the documents ISO 13818-1 , ISO 13818- 
2, ISO 13818-3 and ISO 13818-4, In the context of the 
present patent application, the term includes all vari- 
ants, rmxlifications or developments of MPEG formats 
applicable to the field off digital data transmission. 
[0033] There will now be described, by way of exam- 
ple only, a preferred embodiment of the invention, with 
reference to the following figures, in which: 

Figure 1 shows the overall architecture of a digital 
TV system according to this embodiment: 
Figure 2 shows the architecture of the conditional 
access system of Figure 1 ; 
Figure 3 shows the elements of a receiver/decoder 
for use in this embodiment; 
Figure 4 shows the software architecture of the 
decoder used in this embodiment; 
Figure 5 shows the architecture of the virtual 
machine within the system of Figure 4; 
Figure 6 shows the hierarchy of packets for various 
services in the transmission transport stream; and 
Figure 7 shows the use of an application descrip- 
tion table in relation to applications provided in a 
bouquet of services. 

[0034] An overview of a digital television broadcast 
and reception system 1 is shown in Figure 1. The inven- 
tion includes a mostly conventional digital television 
system 2 which uses the MPEG-2 compression system 
to transmit compressed digital signals. In more detail. 
MPEG-2 compressor 3 in a broadcast centre receives a 
digital signal stream (for example a stream of audio or 
video signals). The compressor 3 is connected to a mul- 
tiplexer and saamWer 4 by linkage 5. The multiplexer 4 
receives a plurality of further input signals, assembles 
one or more transport streams and transmits com- 
pressed digital signals to a transmitter 6 of the broad- 
cast centre via linkage 7, which can of course take a 
wide variety of forms including telecom links. 
[0035] The transmitter 6 transmits electromagnetic 
signals via uplink 8 towards a satellite transponder 9, 
where they are electronically processed and broadcast 
via a notional downlink 10 to earth receiver 1 1 , conven- 
tionally in the form of a dish owned or rented by the end 
user. The signals received by receiver 11 are transmit- 
ted to an integrated receiver/decoder 12 owned or 
rented by the end user and connected to the end users 
television set 13. The receiver/decoder 12 decodes the 
compressed MPEG-2 signal into a television signal for 
the television set 13. 

[0036] A conditional access system 20 is connected to 
the multiplexer 4 and the receiver/decoder 12. and is 
located partly in the broadcast centre and partly in the 
decoder. It enables the end user to access digital televi- 
sion broadcasts from one or more broadcast suppliers. 
A smartcard. capable of decrypting messages relating 
to commercial offers (that is. one or several television 
programmes sold by the broadcast supplier), can be 
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inserted into the receiver/decoder 12. Using the 
decoder 12 and smartcard. the end user may purchase 
events in either a subscription mode or a pay-per-view 
mode. 

5 [0037] An interactive system 1 7, also connected to the 
multiplexer 4 and the receiver/decoder 12 and again 
located partly in the broadcast centre and partly in the 
decoder, may be provided to enable the end user to 
interact with various applications via a nrodemmed back 

10 channel 16. 

[0038] The conditional access system 20 will now be 
described in more detail. 

[0039] With reference to Figure 2, in overview the con- 
ditional access system 20 includes a Subscriber Author- 

15 ization System (SAS) 21. The SAS 21 is connected to 
one or more Subscriber Management Systems (SMS) 
22. one SMS for each broadcast supplier, by a respec- 
tive TOP-IP linkage 23 (although other types of linkage 
could alternatively be used). Alternatively, one SMS 

20 couk) be shared between two broadcast suppliers, or 
one supplier could use two SMSs. and so on. 
[0040] First encrypting units in the form of ciphering 
units24 utilising "mother" smartcards25 are connected 
to the SAS by linkage 26. Second encrypting units 

25 again in the form of ciphering units 27 utilising nfKither 
smartcards 28 are connected to the multipleKtr 4 by 
linkage 29. The receiver/decoder 12 receives a *>jaugh- 
ter" smartcard 30. It is connected direcUy to the SAS 21 
by Communications Servers 31 via the modenrvned 

30 back channel 16. The SAS sends, amongst other 
things, subscription rights to the daughter smartcard on 
request. 

[0041] The smartcards contain the -secrets of one or 
more commercial operators. The "mother* smartcard 
35 encrypts different kinds of messages and the "daughter* 
smartcards decrypt the messages, if they have the 
rights to do so. 

[0042] The first and second ciphering unitS'24 and 27 
comprise a rack, an electronic VME card with software 

40 Stored on an EEPROM, up to 20 electronic cards and 
one smartcard 25 and 28 respectively, for each elec- 
tronic card, one card 28 for encrypting the €CMs and 
one card 25 for encrypting the EMMs. 
[0043] The operation of the conditional access system 

45 20 of the digital television system will now be described 
in more detail with reference to the various components 
of the television system 2 and the conditional access 
system -20. 



[0044] With reference to Figures 1 and 2, in the broad- 
cast centre, the digital audio or v\6eo signal is first <x>nv 
pressed (or bit rate reduced), using the MP€G-2 
55 compressor 3. This oomprassed signal is then transmit- 
ted to the multipl&cer and scrarhbler 4 via the linkage 5 
in order to be multiplexed with other data, such as other 
compressed data. 
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[0045] The scrarr^ler generates a control word used 
in the scrarrtbling process and included In the MPEG-2 
stream in the multiplexer. The control word is generated 
internally and enables the end users integrated 
receiver/decoder 12 to descramble the programme. 
[0046] Access criteria, indicating how the programme 
is commercialised, are also added to the MPEG-2 
stream. The programme may be commercialised in 
either one o1 a number ofsubscription" modes and/or 
one of a number of "Pay Per View" (PPV) modes or 
events. In the subscription mode, the end user sub- 
scrtoes to one or more commercial offers, or "bou- 
quets", thus getting the rights to watch every channel 
inside those bouquets. In the preferred embodiment, up 
to 960 commercial offers may be selected from a bou- 
quet of channels. 

[0047] In the Pay Per View mode, the end user is pro- 
vided with the capability to purchase events as he 
wishes. This can be achieved by either pre-booking the 
event in advance ("pre-book mode"), or ^y purchasing 
the event as soon as it is broadcast ("impulse mode"). In 
the pretended embodiment all users are subscribers, 
whethei' or not they watch in subscription or PPV mode, 
but of course PPV viewers need not necessarily be sub- 
scrft>ers. 

Entmerhent Control Messages (ECWisl 

[604iBi Both the control word and the access criteria 
are used to build an Entitlement Control Message 
(ECM). This is a message sent in relation with a scram- 
bled program: the message contains a control word 
(which allows for the descrambling of the program) and 
the access criteria of the broadcast program. The 
access criteria and control word are transmitted to the 
second encrypting unit 27 via the Iinkage29. In this unit, 
an ECM Is generated, encrypted and transmitted on to 
the multiplexer and sciambler 4. During a broadcast 
transmission, the control word typically changes every 
few seconds, and so ECMs are also periodically trans- 
mitted to enat)le the changing control word to be 
descrambled. For redundancy purposes, each ECM 
typically includes two control words; the present control 
word and the next control word. 
[0049] Each service broadcast by a broadcast sup- 
plier in a data stream comprises a number of distinct 
components: tor example a televisk)n programme 
Includes a video component, an audio component, a 
sub-title component and so on. Cach of these compo- 
nents of a servk^e is indivkiually scrambled and 
encrypted for subsequent broadcast to the transponder 
9. In respect of each scrambled component of the serv- 
ice, a separate ECM is required. Alternatively, a single 
ECM may be required for all of the scrambled compo- 
nents of a sen/ice. Multiple £CMs are also generated in 
the case where multiple conditional access systems 
<x>ntrol access to the same transmitted program. 



Programme Transmission 

[0050] The multiplexer 4 receives electrical signals 
comprising encrypted EMMs from the SAS 21. 

5 encrypted ECMs from the second encrypting unit 27 
and compressed programmes from the compressor 3. 
The multiplexer 4 scrambles the programmes and 
sends the scrambled programmes, the encrypted 
EMMs and the encrypted ECMs to a transmitter 6 of the 

70 broadcast centre via the linkage 7. The transmitter 6 
transmits electromagnetic signals towards the satellite 
transponder 9 via uplink 8. 

Proqrpmme Pcwptipn 

75 

[0051 ] The satellite transponder 9 receives arvj proc- 
esses the electromagnetic signals transmitted by the 
transmitter 6 arid transmits the signals on to the earth 
receiver 1 1 , conventionally in the form of a dish owned 

20 or rented by the end user, via downlink 10. The signals 
received by receiver 1 1 are transmitted to the integrated 
receiver/decoder 1 2 owned or rented by the end user 
and connected to the end users television set 13. The 
receiver/decoder 12 demultiplexes the signals to obtain 

2S scrambled programmes with encrypted EMMs and 
encrypted ECMs. 

[0052] If the programme is not scrambled, that is, no 
ECM has been transmitted with the MPEGi-2 stream, 
the receiver/decoder 12 decompresses the data arxi 
30 transforms the signal into a video signal tor transmission 
totelevisfonset 13. 

[0053] If the programme is scrambled, the 

receiver/decoder 12 extracts the corresponding ECM 
from the MPEG-2 stream and passes the ECM to the 

35 "daughter" smartcard 30 of the end user. This slots into 
a housing in the receiver/decoder 12. The daughter 
smartcard 30 controls whether the end user has the 
right to decrypt the ECM and to access the programme. 
If not, a negative status is passed to the 

40 receiver/decoder 12 to indicate that the programme 
cannot be descrambled. If the end user does have the 
rights, the ECM is decrypted and the control word 
extracted. The decoder 12 can then descramble the 
programme using this control word. The MPEG-2 

45 stream is decompressed and translated into a video sig- 
nal for onward transmission to television set 1 3. 

Entitlement Management Messages (EMMs^ 

so [0054] The EMM is a message dedicated to an indi- 
vidual end user (subscriber), or a group of ervj users. 
Each group may contain a given number of end users. 
This organisation as a group aims at optimising the 
bandwidth; that is. access to one group can permit the 

55 reaching of a great number of end users. 

[0055] Various specific types of EMM can be. used. 
Indivklual EMMs are dedicated to IrKlivklual subscrib- 
ers, and are typically used in the provisfon of Pay Per 
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View services: these contain the group identifier and the 
position of the subscriber in that group. 
[0056] Group subscription EMMs are dedicated to 
groups of say. 256 individual users, and are typically 
used in the administration of some subscription serv- 
ices. This EMM has a group identifier and a subscribers' 
group bitmap. 

[0057] Audience EMMs are dedicated to entire audi- 
ences, and might for example be used by a particular 
operator to provide certain free services. An "audience" 
is the totality of subscribers having smartcards which 
bear the same conditional access system identifier (CA 
ID). Finally, a "unique" EMM is addressed to the unique 
identifier of the smartcard. 

Subscriber ftona^ement System (SMS) 

[0058] A Subscriber Management System (SMS) 22 
includes a database 32 which manages, amongst oth- 
ers, all of the end user files, commercial offers, sub- 
scriptions. PPV details, and data regarding end user 
consumption and authorization. The SMS may be phys- 
ically remote from the SAS. 

[0059] Each SMS 22 transmits messages to the SAS 
21 via respective linkage 23 which imply modifications 
to or creations of Entitlement Management Messages 
(EMMs) to be transmitted to end users. 
[0060] The SMS 22 also transmits messages to the 
SAS 21 which imply no modifications or creations of 
EMMs but imply only a change in an end user's state 
(relating to the authorization granted to the end user 
when ordering products or to the amount that the end 
user will be charged). 

[0061] The SAS 21 sends messages (typically 
requesting information such as call-back information or 
billing information) to the SMS 22. so that H will be 
apparent that communication between the two is two- 
way. 

Subscriber Authorizat ion System fSASl 

[0062] The messages generated by the SMS 22 are 
passed via linkage 23 to the Subscriber Authorization 
System (SAS) 21, which in turn generates messages 
acknowledging receipt of the messages generated by 
the SMS 21 and passes these acknowledgements to 
the SMS 22. 

[0063] In overview the SAS comprises a Subscription 
Chain area to give rights for subscription mode and to 
renew the rights automatically each month, a Pay Per 
View Chain area to give rights for PPV events, and an 
EMM Injector for passing EMMs created by the Sub- 
scription and PPV chain areas to the multiplexer and 
scrambler 4, and hence to feed the MPEG stream with 
EMMs. If other rights are to be granted, such as Pay Per 
File (PPF) rights in the case of downloading computer 
software to a users Personal Computer, other similar 
areas are also provided. 



[0064] One function of the SAS 21 is to manage the 
access rights to television programmes, available as 
commercial offers in subscription mode or soM as PPV 
events according to different nxxles of commercialisa- 

5 tion (pre-book mode, impulse mode). The SAS 21. 
according to those rights and to information received 
from the SMS 22. generates "EMMs for the subscriber. 
[0065] The EMMs are passed to the Ciphering Unit 
(CU) 24 for ciphering with respect to the management 

10 and exploitation keys. The CU completes the signature 
on the EMM and passes the EMM back to a Message 
Generator (MG) In the SAS 21. where a header is 
added. The ^MMs are passed to a Message Emitter 
(ME) as complete EMMs. The Message tBenerator 

15 determines the broadcast start and stop time and the 
rate of emission of the EMMs, and passes these as 
appropriate directions along with the EMMs to the Mes* 
sage Emitter. The MG only generates a given EMM 
once; it is the ME which performs cyclic transmission of 

20 the EMMs. 

[0066] On generation of an £MM. the MG assigns a 
unique identifier to the EMM. When the MG passes the 
EMM to the ME. it also passes the -EMM ID. This ena- 
bles identification of a particular EMM at both the MG 

26 and the ME. 

[0067] In systems such as simulcrypt which are 
adapted to handle multiple conditional access systems 
e.g. associated with multiple operators. EMM streams 
associated with each conditional access system are 

30 generated separately and multiplexed together by the 
multiplexer 4 prior to transmission. 

Receiver/decoder 

35 [0068] Referring to Figure 3. the elements of a 
receiver/decoder 12 or set -top box for use in a digital 
broadcast system and adapted to be used in the 
present invention will now be described. As will be 
understood, the bask: elements of this decoder are 

40 largely conventional and their inrplementation will be 
within the capabilities of one skilled in the art. 
[0069] As shown, the decoder 12 is equipped with 
several interfaces for receiving and transmitting data, in 
particular a tuner 40 for receiving broadcast MPEG 

46 transmissions, a serial interface 41, a parallel interface 
42. and a modem 43 for sending and receiving data via 
the telephone network. The decoder also includes a f irst 
and second smart <»rd reader 44 and 45, the first 
reader 44 for accepting a subscription smart card and 

50 the second reader 45 for accepting bank arxl/or other 
smart cards. 

[0070] The decoder also includes a receiver 46 for 
receiving infra-red control signals from a handset 
remote -control 47 and a Peritel ouput for sending audio- 
55 visual signals to a television 13 connected to the 
decoder. 

[0071] Processing of digital signals r^eceived via the 
interfaces and generation of output signals is handled 
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by an ensemble of hardware and software elements 
here grouped together as a certtral control unit 48. 
[0072] The software architecture of the control unit 
within the decoder will be described below in relation to 
Figures 4 and 5. tn broad terms, the system uses a vir- s 
tual machine interacting via an interfece layer with a 
lower level operating system Implemented in the hard- 
ware components of the decoder. In terms of hardware 
architecture, the control unit 48 is equipped with a proc- 
essor, memory elements such as ROM, RAM. FLASH io 
memory etc. as in known decoders. 
[0073] Applications processed by the control unit 48 
may be resident applications stored in the ROM or 
FLASH of the decoder or applications broadcast and 
downloaded via the MPEG Interface 2 of the decoder. 75 
Applications can include program guide applications, 
games, interactive services, teleshopping applications, 
as well as initiating applications to enak>le the decoder 
to be immediately operational upon start-up and appli- 
cations for configuring aspects of the decoder. Applica- po 
tions are stored in memory locations in the decoder and 
represented as resource files comprising graphic object 
descriptions files, unit files, variables block files, instruc- 
tion sequence files, applications files, data files etc. 

Decoder gygtgm Architecture 

[0074] Turning now to the software architecture of the 
system within the receiver/decoder as shown in Figure 
4. it will be seen that a layered architecture is used. The 30 
first layer 51 represents the operating system of the 
hardware of the receiver/decoder. This is a real-time 
operating system chosen by the manufacturer to control 
the hardware elements of the receiver/decoder: The 
real-time operating system has a relatively fast 36 
response time in order to be able to correctly synchro- 
nise hardware operations. The data processing system 
sits on top of the hardware operating system and com- 
prises a middleware layer 52 and an application inter- 
face layer 53. 40 
[0075] Event messages are passed between the oper- 
ating system layer 51 and the middleware layer 52 
Immediately above. The middleware layer is written in a 
language such as C ANSI and comprises the elements 
of a virtual machine 54 and a nunrrioer of interfaces 55 45 
including a graphical interlace 56, a FLASH/PROM 
memory interface 57, a protocol interlace 58 and a 
device interface 59. 

[0076] The use of a virtual machine enables in partic- 
ular to provide indeperxlence between upper level appli- so 
cations 66, 67 described in further detail below and 
usually provided by the system manager or one or more 
operators, and a lower level operating system 51, usu- 
ally implemented by the hardware manufacturer of the 
decoder. ss 
[0077] The interfaces 60 provide the link between 
operations of the virtual machine and the lower level 
operating system 51 and also include a number of inter- 



mediate level application nruxJules more easily executed 
at this level. 

[0078] The application interface (API) layer 53 com- 
prises a number of high level packages 60-65, written in 
an object-oriented interpretative language, such as 
Java. These packages provide an interface between the 
high level applications generally created by the service 
provider (interactive program guide, teleshopping. inter- 
net browser etc) and the virtual machine of the system. 
Examples of such applications are given below. 
[0079] The lower level OS is normally embedded in 
the hardware components of the decoder, although in 
some realisations, the lower level OS can be down- 
loaded. The middleware and application interface layer , 
packages can be downloaded into the RAM or FLASH 
memory of the decoder from a broadcast transmission. 
Alternatively, some or all of the middleware or applica- 
tion interlace layer elements can be stored in the ROM 
or (if present) FLASH memory of the decoder. As will be 
understood, the physical organisation of the memory 
elements of tiie decoder is distinct from the logical 
organisation of the memory. 

Applications and Application Manager 

[0080] As shown in Figure 4, a number of high level 
applications 66 sit on top of and communicate with 
lower levels in the system via the application interface 
layer 53. As will be described below, applications may 
originate from a variety of sources and/or operators. 
The overall control of such applications will be canried 
out by an application rhanager 67, itself installed as an 
application and responsible for managing the downtoad- 
ing of broadcast applications, the rights of certain appli- 
cations to address and control lower layers of the 
system etc. 

Application Interface Laver 

[0081] Referring to the application interface layer 53 
shown in Figure 3, and as described akxive. the pack- 
ages in this layer are written in an object oriented lan- 
guage such as Java. Each package defines a set of 
dass libraries called on during operation of the system. 
In the present system. the folkjwing packages are 
installed. 

[0082] Lang/Util Package 60. These packages define 
the classes necessary for the manipulation of objects by 
the virtual machine. These dass libraries normally form 
part of a standard library assodated with the okject ori- 
ented language chosen. 

[0083] MHEG-5 f=»ackage 61. This package defines 
the classes associated with the manipulation of graphi- 
cal objects on the television display. Such objects are 
distinct from audio-visual data and can make up, for 
exanrple. channel identifiers or text laid over displayed 
images. The definition of classes within this package 
should respect the MHEG-5 norms defined by tiie 
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standards ETS 300777-3 and ISO/ISE 13522-5 (and 
the standard ISO/ISE 13522-6 in the case of a Java 
implemented system). 

[0084] Toolbox Package 62. This package contains 
the classes used for downloading and decompression s 
of information as well as the classes associated with the 
management of the file system and memory within the 
receiver/decoder and the classes associated with the 
connection to the internet etc. 

[0085] Device Package 63. This package defines the io 
classes necessary for management of peripherals 
attached to the receiver/decoder, as discussed above 
and including the modem, the smart card readers, the 
MPEG flow tuner etc 

[0086] Service Package 64. This package defines the 75 
classes necessary for the implementation of developing 
higher level interactive applications, such as manage- 
ment of aedit card data etc. 

[0087] OSMCC-UU Package 65. This package imple- 
ments the protocols necessary for communication so 
between a client and a server for data file search and 
reading. Implementation of this package should respect 
the norm ISO/IEC 13818-6 and directives defined in 
DAVIC part 9. 

[0088] A further layer of interactive applications, writ- 25 
ten by the service provider and downloaded during 
broadcast as in conventional systems, will be laid over 
the interface packages defined above. Depending on 
the applications to be Introduced, some of the above 
packages may be omitted. For example, if the service 
provider does not Intend to provide a common way for 
data reading, the DSMCC-UU package nfiay be left out 
of the final system. 

[0089] The packages 53 provide class libraries for an 
object-oriented programming environment Their class 
behaviour will depend on the language chosen. In the 
case of a Java application, for example, a single inherit- 
ance class structure will be adhered to. 

imgrfgce Uiyer 

[0090] As shown, the interface layer is composed of 
four modules, a graphics module 56, a memory file 
management module 57, a protocol module 58 and a 
device manager 59. Whilst the modules at this level are 
described as interface modules their function is to pro- 
vide a "glue" layer for the implementation of the applica- 
tion interface packages and for the operation of the 
virtual machine generally. 

[0091 ] The graphics module 56. for example, provides 
the creation arxl management of graphical objects, ft 
asks the low level OS to display basic graphic shapes 
such as single pixels, lines, rectangles etc. The imple- 
mentation of this module depends on the graphics 
capability of the low level manufacturers OS. In some 
ways conrplementary to the MHEG-5 package 4311. 
these functions may be more efficiently executed at this 
code level than in the high level code chosen for the 



application layer above. 

[0092] In a similar manner, the memory file manage- 
ment module 57 includes low level read/write file com- 
mands associated with the memory components of the 
system. Typically, the hardware operating system only 
includes commands necessary to readywrite a sector or 
page within a memory component. As with the graphics 
module 56, this module enables a set of simpler lower 
level applications to be efficiently Introduced in the sys- 
tem. 

[0093] The protocol management module 58 defines 
a library of communication protocols that may be called 
upon in communications via. for example, the TOP/IP 
layer of the decoder. 

[0094] Th e device manager 59 is slightly different from 
the other modules in this layer in that it provides the link 
or interface between the hardware operating system 
and the layers above, including the other modules in the 
interface layer and the virtual machine. Commands or 
event messages that are received/sent to the hardware 
OS from the virtual machine, for example, are necessar- 
ily passed by the device manager for conversk>n 
according to the interface specifications between the 
two levels. 

Virtual Machine Description 

[0095] Refen^ing now to Figure 5, the structure of the 
virtual machine 54 used in the system of the present 
invention will be described. The virtual machine used in 
the present invention is a pre-emptive multithread type 
machine. The general characteristk:s of such a machine 
are known in other contexts outside of the audk>-visua1 
and digital television f iekis and the following description 
will focus on those areas that are the most specific to 
the present applk:ation. 

[0096] The virtual machine is composed of a number 
of elements, which interact broadly as shown in Figure 

5. 

[0097] The scheduler 70 composed of a thread man- 
ager service 71 and a monitor manager service 72 
forms the heart of the multithread machine. The sched- 
uler 70 orders the execution of threads created by appli- 
cations externally of the virtual machine and those 
created by the virtual machine itself <e.g. a gart>age col- 
lection thread). 

[0098] The event manager 73 handles an event rout- 
ing tak)le and the lists of events subsaibed to by the 
threads and centralises the dispatch of event treat- 
ments. 

[0099] The memory manager 74 handles the alloca- 
tion and disallocation of the memory zones within the 
system memory and also handles the removal from the 
memory of non-referenced objects {gartjage collection). 
[01 00] The dass manager 75 charges the classes of 
the application code downloaded in a broadcast signal, 
interacting with the security manager 80 to check the 
integrity of downloaded code and with the file manager 
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76. which implements the applications. 
[0101] The file manager 76 canies out the implemen- 
tation of the system files and the handles the mecha- 
nism of downloading of Interactive applications and 
data. 

[0102] The security manager 80 handles the level of 
access permitted to downloaded applications, some 
applications having the ability to carry out more opera- 
tions than others in relation to the file system. 
[0103] The interpreter 77 comprising a bytecode inter- 
pretation service 78 and a "m-code" interpretation serv- 
ice 79 handles the interpretation of applications written 
in these two codes, bytecode being associated with 
Java applications and m-code being the name given to 
a proprietary code developed by the applicants. 
[0104] As set out abos/e, the decoder is adapted to 
implement and execute applications downloaded in 
transport packets and data tables from the transport 
stream broadcast by the satellite, cable or terrestrial 
system. There will now be desaibed, with reference to 
Figure 6. the organisation of these and other such data 
tables within a conventional MPEG-2 datastream. 

Organisation of Data Tables within the Transport 
Stream 

[01 05] As shown in Figure 6, the broadcast data trans- 
port stream corrtains a number of packets of standard 
format, including a programme association table 90 
("PAT^, the RID in the header of the packet being fixed 
by the MPEG-2 staridard for this packet at a value of 
0x00. The programme access table 90 provides the 
entry point for access to programme data and contains 
a tat^e referring to the PID values of the programme 
map tables ("PMT") 91 , 92 associated with a given serv- 
ice or channel within the stream. Each programme map 
table 91 . 92 contains in turn a reference to the PID val- 
ues of the packet streams of the audio tables 93 and 
vkJeo tables 94 associated with that service. 
[0106] As shown, the programme nnap table 92 also 
contains references to the PID values of other packets- 
95. 96, 97 containing additional data relating to the 
service in question, in particular. ECM data generated 
by a number of conditional access systems and associ- 
ated with the servrce in question as well as application 
data carried by this service. 

[0107] In addition to the programme access table PAT 
90. the MPEG transport stream further conrprises a 
conditional access table 101 fCAT"). the PID value of 
which is fixed at 0x01 . Any packet headers containing 
this PID value are thus automatically identified as con- 
taining access control information. The CAT table 97 
refers to the PID values of MPEG packets 98, 99. 100 
referring to EMM data associated with one or more con- 
ditional access systems. As with the PMT packets, the 
PID values of the EMM packets referred to In the CAT 
table 101 are not fixed and may be determined at the 
choice of the system operator. 



[01 08] The MPEG-2 standard specifies very few fixed 
PID values outside of the PAT table value and the CAT 
table value referred to above. The majority of PID values 
within a certain range may therefore be determined by 
5 an operator. As will be descrO^ed in greater detail below, 
the preserrt emkxxjiment of the invention proposes a 
fixed PID value to be assigned to a tattle containing data 
relating to applicatbns carded in a number of services 
and bouquets. 

10 

Formpt of Trpnsport PPChets gntf Pilvpte Section 
Data 

[01 09] As is known. MPEG transport packets are of a 
75 fixed length of 188 bytes including a header. In a stand- 
ard packet, tiie three bytes of the header following the 
synchronisation data comprise: 



20 


TABLE) . 






Transport error indicator 


1 bit 




Payload unit indicator 


1 bit 


2S 


Transport priority 


1 bit 


PID 


13 bits 




Transport scrarrt)ling control 


2 bits 




Adaptation field control 


2 bits 


30 


Continuity counter 


4 bits 



[0110] The characteristics of these fields are largely 
determined by the MPEG standard. 

35 [01 1 1 ] The above describes the format of the header 
of a transport packet. In conformity with the MPEG-2 
standard, information contained with a packet payload 
is subject to a further level of structure according to the 
type of data k>eing transported. In the case of audio, vis- 

40 ual. teletext, subtitie or other such rapidly evolving and 
synchronised data, the information is assembled In the 
form of what is known as a packetised elementary 
stream or PES. This data stream, which is formed by 
assembling the payk>ads of the transmitted packets. 

45 itself comprises a sequence of packets, each packet 
comprising a packet header and payload. Unlike the 
transmitted packets in the transport stream, the lengtii 
of PES packets is variable. 

[01 1 2] In the case of some other types of data, such 
50 as applicatk>n data or ECM and -EMM data, a different 
format from PES packeting is proscribed. In particular, 
data contained in the transport packet payload is 
divided into a series of sections or tattles, the table or 
8ectk>n header including a table ID or TID identifying tiie 
55 table in question. Depending on the size of the data, a 
section may be contained entirely within a packet pay- 
load or may be extended in a series of tables over a 
numk>er of transport packets. In the MPEG-2 context. 



9 




17 EP0 989 

the term "table" is often used to reler to a single table of 
data, whilst "section" usually refers to one of a plurality 
of tables with the same TID value. 
[01 1 3] The actual TID values used to refer to informa- 
tion carried in these tables or sections are not fixed by 5 
the MPEG-2 standard and may be defined at the discre- 
tion of the operator of a service or bouquet of services. 
[0114] As with transport packet data and PES packet 
data, the data structure or syntax of a table or section is 
nevertheless additionally defined by the MPEG-2 stand- io 
ard. Two possible syntax forms for private table or sec- 
tion data are proposed; a long form or a short form. 
[0115] In both the short and long form, the header of 
a private table includes at least the data comprising: 



TABLE II 


Table id 


8 bits 


Section syntax indicator 


1 bit 


Private indicator/reserved 


1 bit 


ISO reserved 


2 bits 


Section length 


12 bits 



[0116] The private indicator and private section 
lengths are comprised of data not fixed by the MPEG-2 
standard and which may be used by the system opera- 
tor lor his own purposes. For further information regard- 30 
ing table syntax, the reader is referred to the MPEG-2 
standard. 

A pplicatioiifi accessed v ia one or more PMT tables 

35 

[0117] As will be understood from the above, each 
PMT table defines a particular service or channel and 
the information available on this service. Within a given 
service, for example, a plurality of audio and video 
streams may be carried, for example, to enable a viewer 40 
to watch a sporting event broadcast on that service from 
a number of different angles. 

[0118] The service may also contain applications 
downloaded and executed by the decoder, for example, 
such as an interactive shopping application or an inter- 45 
active meteorological chart The number and type of 
applications carried in the service arxi accessed via its 
PMT table can vary greatly. In the case of a dedicated 
weather channel, for example, the majority of the data 
can-ied by the channel may relate to an application exe- so 
cuted by the decoder such that there Is. for example, no 
real-time video data carried by this service. 
[0119] In a bouquet of services, some applications 
such as a start-up application may be carried by all 
services whilst some applications may be exclusive to ss 
one service, for example, an application containing 
information relating directly to a programme being 
shown only on that service. 
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[0120] Conventionally, ail data regarding the applica- 
tions carried by a given service is contained in the rele- 
vant PMT table tor that service. Each PMT table carries 
information on the complete set of applications used by 
that service and provides the point of access to these 
applications. 

[0121] Upon selection of a service, the application 
managers of conventional systems execute a predeter- 
mined sequence of decisions wHh regard to the applica- 
tions carried in the service and, if already tuned to a 
service, those applications currently running in the 
decoder. Applications that are not already present in the 
decoder but which are contained in the new service are 
downloaded from the service. If a more recent version 
to that running in the decoder is carried in the service, 
this is downloaded and the older version deleted. Appli- 
cations which are running and which are listed in the 
new service in the same (or an older version) are main- 
tained. Applications that are not listed in the new serv- 
ice but that are cun^ently running are deleted. 
[01 22] This latter operation of the application manager 
found in conventional decoder systems can in particular 
lead to a number of problems. In the case, for example, 
where a user changes from one channel to another and 
back again, an application may be deleted and then re- 
installed. As will be understood, installation of an appli- 
cation can take some time depending on the size of the 
application and the available memory in the decoder. 
[0123] Furthermore, upon each change of channel, 
the decoder is required to download and analyse the 
PMT table data before having sufficient information to 
carry out any action regarding applicatioris to be down- 
loaded or currently running. This may take some time. 
As mentioned above, each service is completely Inde- 
pendent and includes all applications necessary to the 
operation of the service and the information regarding 
such applications is carried in the PMT table of that 
service. 

[01 24] In such a context, the case of applications cur- 
rently running in the decoder and that are not listed In 
the PMT table of the new service poses a problem, 
since the applk:ation manager has no information 
regarding which of the currently running applications 
may be maintained with impunity upon changing to this 
service, and whk:h need to be deleted. Most current 
systenis act simply to delete currently running applfca- 
tions to permit downloading of new apprications. 
[01 25] Referring to Figure 7, there will now be defined 
a data format for tables and secttons in the MP€G trans- 
port stream which enal3le5 the problems of the krKSwn 
systems to be overcome. 

Apptication Description Table 

[01 26] As shown in Figure 7. the transport stream 
includes, in addition to the PMT1 and PMT2 tables 91, 
92 used to define the data contained in a first and sec- 
ond service, an appllcatton desaiption table or tables 



10 



m • 

19 EP 0 989 743 A1 20 



110. Ill for each available bouquet of services. ADT 
B1 designates the table for a first bouquet of services, 
ADT 62 the table tor a second bouquet etc. 
[0127] In a similar nnanner to the PAT and CAT tables, 
the PID value of an ADT table is fixed at a value not s 
presently reserved or prohibited by the MPEG-2 stand- 
ard. All application description or ADT tables in all serv- 
ice bouquets are referred to by this PID value and. 
preferably, a fixed TID value. In order to permit different 
ADT tables for different service bouquets, a specific TID 
extension value is assigned to each ADT table associ- 
ated with a bouquet of services. These TID extension 
values do not need to be fixed and may be decided by 
common agreement between the operators of each 
bouquet. 

[0128] As will be understood, whilst the present 
embodiment of the invention uses an ADT table per 
bouquet of services, the concept may be generalised to 
the use of a single global ADT table covering all serv- 
ices across all bouquets. In view of the differences 
between operators running each bouquet of services, 
this may be difficult to implement, since it would imply 
the creation of a "super operator" charged with compil- 
ing information for all operator bouquets and creating 
the global ADT table. 

[0129] A decoder is normally configured to receive a 
bouquet of services in dependence on the rights trans- 
mitted by a subscription smart card or PCMCIA card 
inserted in the decoder. Based on the information 
received from the SLd>scription card, the application 
manager within the decoder may then download the 
ADT table having the appropriate TID extension value 
associated with this bouquet. 

[0130] Changing the subscribed bouquet by changing 
the associated subscription card will cause the decoder 
to download the ADT table associated with the new bou- 
quet of services and refen^ed to by its own unique TID 
extension value. The TID extension value may be given 
directly in the information received from the subscription 
card, or may be derived from a table in the decoder. 
Equally, the decoder may be configured to the correct 
TID extension value by other means, for example, via a 
modem link. 

[01 31 ] Alternatively, the decoder may be configured to 
scan and filter all ADT tables in the transport stream 
using the fixed PID. TID values. As will be described 
below, within each ADT table is a reference to the PMT 
value of the services to which the ADT table applies. 
From this information, the decoder ^n deduce which 
ADT table applies when operating in relation to a partic- 
ular bouquet of services. 

{0132] As shown, an ADT table 110 associated with 
the bouquet of services 81 is divided into three parts: a 
service description part 1 12. an application desertion 
part 113 and an (optional) signature part 114. 
[01 33] The service description part 1 1 2 contains infor- 
mation regarding which applications A1 , A2, A3 etc. are 
earned by each service PMTI, PMT2 etc. in the bou- 



quet of services 81. Each application is identified by a 
unique application ID (A1, A2 etc.). 
[0134] In Figure 7. the service description part 112 
identifies the service PMT1 as being associated with 
the applications A1, A3 etc. and the service PMT2 as 
being associated with the applications A1 . A2. A4 etc. 
(01 35] The application description part 1 1 3 of the ADT 
table contains a description of the applications accessi- 
ble via all services of the tx)uquet and links the applica- 
tion ID to data describing the characteristics of this 
application. The description typically contains the fol- 
lowing parameters: 

Application_id. The application_id enables identifi- 
cation by the Application Manager of the applica- 
tions carried in each service of the bouquet In this 
embodiment, since a different ADT table is associ- 
ated with each bouquet, another bouquet of serv- 
ices may refer to its own applications by the same 
ID values and an application is therefore only 
uniquely identified by the pair of values 
(applicationjd, bouquet_id). 
Application type: The type of the application, for 
example, a pure Java language application or a 
MHEG-5 application. This definition of type is nec- 
essary because the activation of an application can 
be completely different depending on its type and 
since different types of application may be carried 
in the same bouquet of services. Type can also 
include the version number of the software. 
Application_name: The name of the application as 
kriown by or displayed to the user. This is typically 
the name that the user will see when the applk^ation 
is started. For example, we can imagine writing a 
message in a window: "launching PILOT" upon acti- 
vation of an application named "PILOT*. 
AppUcation_bootinfo: The access point of the appli- 
cation (depending on the application jtype) that the 
application manager has to address in order to 
download and to launch the application. 
Application jflag: This field gives the behavior of the 
application concerning downloading, launching, 
etc. In particular, this field may be used to define 
whether an application is to be maintained or killed 
when changing between services in the bouquet, 
irrespective of any indications in the PMT table of 
the services in question. 

Applk»tion_key. The remote control key or other 
input action associated with activation of the appli- 
cation. For example, in case of a pifot or navigator 
type application, the applrcation^key may be a but- 
ton of the remote comrol associated with the activa- 
tion of the pilot. For auto-start applications, the 
apptication_key value may be a default value. 
Application_exclusive. A flag to indteate that an 
application is exclusive to a servfoe. This enables a 
list of applicationjds exclusive to each service to 
be assembled by the application manager, the 
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application manager acting to delete an application 
in the case of changing to another service. 
Application_priority. The priority of the application, 
for example, between min(l) and max(7). In this 
regard, priority can refer to the priority of access to 
resources within the decoder and/or priority in 
terms of downloading of an application. If desired, 
two separate priority fields may be used to reflect 
this difference. 

Application_memory. The memory size necessary 
for the application to be downloaded. This corre- 
sponds not only the size of the application but to an 
estimation of the maximum amount of memory that 
will be used by the application itself and its data. 
Application_version. The present version of the 
application. 

DVB triplet. This identifies a list of services, for 
applications which are specific to a service. The 
DVT triplet is made-yp of an original Network.td. a 
TransportStream_ld and a Service_ld. 

[0136] As will be appreciated, many types o1 informa- 
tion may be included and the factors in akx)ve list are not 
intended to be exhaustive and/or obligatory. 
[01371 Other information in the application description 
part may include information needed to locate modules 
of an application contained within a further level of 
structure in the TID tables of sections of the service. For 
example, in addition to being packetised in tables and 
sections for transmission, an application may itself be 
organised in a data carousel, for example, conforming 
to the DSMCC data format. The information contained 
in the ADT can include a path description or carousel 
address to enable the decoder to go to a specific entry 
point to download an application. 
[0138] Finally, the ADT table 110 includes a signature 
1 14 comprising an electronic signature of the data in the 
ADT table 110 and which enables the decoder to verify 
the origin and integrity of the data in the table. 
[01 39] This may be created by the operator responsi- 
ble for the t>ouquet, for example, using a combination of 
a hash algorithm (such as MD5) to obtain a hash value 
con^esponding to the data in the table, this hash value 
then being encrypted by a private key of a public/private 
algorithm (such as RSA). Verification of the ADT table 
may be carried out by a decoder possessing the same 
hash algorithm and supplied with the conresponding 
public key. The use of a combination of hash and pri- 
vate/public key algorithms to verify communicated data 
is known and will not be described here in any further 
-detail. 

[0140] Alternatively or in addition, the ADT table may 
even be encrypted by a symmetric algorithm. However 
as will be understood, use of an electronic signature at 
this level is optional and. in practice, verification may be 
canied out at a lower level, for example, on the applica- 
tion data itself. 

[0141 ] As described above, the ADT table for a given 



bouquet will have a predetermined PID and TID exten- 
sion value and this table will be loaded and verified 
immediately upon start up of the decoder, regardless of 
which service channel (if any) the decoder is tuned to. 

5 Once supplied with the information in this table, the 
application manager can then make reasoned choices 
regarding mairrtenance or non-mairrtenar»ce of applica- 
tions when tuned to or changing between services and 
without having to wait the downloading of a PMT table. 

10 [0142] In particular, upon selection of a service or 
upon changing servk;es the applk»tion manager may 
take into account information contained in the 
applk;ationJlag, application.exclusive. 
applrcation ^priority and applteation_memory fields in 

75 evaluating which applications to download, which appli- 
cations to maintain. whk:h applications must be deleted 
etc. 

[0143] In the case of a decoder tuned firstly to the 
service channel PMTl shown in Figure 7. the applica- 

20 tion manager will identify the applk:ations A1 . A3 con- 
tained within this service channel as being present and 
valid, that is as applk:ations corresponding to applk»- 
tions listed in the service section 1 12 of the ADT table of 
the bouquet. Using the ADT table data for these applk:a- 

25 tions, the application manager then carries out a deter- 
mination as to whether or not to download the 
applications and. assuming all conditions are met<suff i- 
cient memory etc.) will download applk^ations A1 , A3 
etc. 

30 [0144] If the user now changes to the«ervk;e channel 
PMT2. the application manager will identify the applica- 
tions A1 . A2. A4 as being present and valid in this chan- 
nel. 

[0145] In the case of the application A1 . the applk:a- 

35 tion manager will be aware that this applicatk>n is 
already downloaded and present in the decoder in its 
latest version and will normally not carry out any action, 
leaving A1 running "as is" in the decoder. In the -case of 
the applications A2, A4 the application manager may, 

40 for example, evaluate the values applicatton^prlority. 
application_memory etc. of these applications arxJ com- 
pare these values with the corresponding values of the 
application A3 previously downloaded and currently 
running in the decoder. The evaluation may alsobe-car- 

45 ried out using the value appr»cation Jlag of the currently 
running applk^tion (see above). 
[0146] Even though the application A3 rs not present 
and not required for all access to the possibilities pro- 
vided by the eervice channel aocessed via PMT2, the 

50 applk;ation manager may nevertheless decide in 
dependence on the value applicationjf lag to continue to 
run the applkation A3 in preference to. or as well as, 
downloading one or the other of the applications A2. A4. 
If the user then changes t>ack to PMTl. the applk:atfon 

55 A3 is thus immediately available. 

[0147] Many other alternatives are possible. For 
example, the application manager may be configured to 
kill the applk^ation A1 (for example if A1 includes an 
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application_exclusive flag associated with PMTl); to 
maintain A3 for a iinnrted period of time before kiiling A3 
and downloading A2. A4; to maintain A3 until the user 
presses a Key on the remote control and thereafter kill 
A3 and download one of the applications A2. A4 etc. 
[01481 As will be understood, the use of an ADT table 
containing data over all services in a bouquet enables 
the application nrtanager of the decoder to carry out an 
unusually sophisticated evaluation regarding the main- 
tenance or non-maintenance of applications carried in a 
plurality of service streanfis. 

[0149] In the above example, the ADT table has been 
described as being downloaded from the broadcast 
transport stream. In practice, the ADT table, or at least 
a start up version of the ADT table, may be loaded into 
the decoder at the moment of manufacture of the 
decoder, so as to enable the decoder to automatically 
load certain applications carried in some or all services 
in a bouquet Alternatively, the decoder may download a 
version of the ADT table via its modem connection, via 
the smart card interface, via the serial port etc. 

Claims 

1. A method of transmission of application data in a 
plurality of services in a digital transport stream 
characterised in providing an application data table 
containing information regarding the application or 
applications carried by each of a plurality of the 
services within the transport stream. 

2. A method as claimed in claim 1 in which the appli- 
cation data table is transported in a transport 
packet having a predetermined packet ID or PID 
value associated with the presence of an applica- 
tion data table within the packet. 

3. A method as claimed in daim 1 or 2 further com- 
prising providing a plurality of application data 
tables, each application data table containing infor- 
mation regarding applications contained within a 
bouquet of services. 

4. A method as claimed in claim 3 in which each appli- 
cation data table is transported in a table or section 
within a transport packet, each applicatk)n data 
tat)le being associated with a table or section hav- 
ing a characteristic table ID or table ID extension 
value. 

5. A method as claimed in any preceding daim in 
which the or each application data table is electron- 
ically signed so as to permit a decoder to verify an 
application data table as originating from a known 
operator. 

6. A method as daimed in any preceding daim in 
whkHi each service further comprises a programme 



map table giving access to applications carried by 
this service, the programme map table itself com- 
prising information regarding the or each applica- 
tion carried by this service. 

5 

7. A method as claimed in any preceding claim in 
which the application data table further comprises 
information regarding which applications may be 
accessed via each service. 

70 

8. A method as claimed in any preceding daim in 
which the application irrfbrmation carried in the 
application data table further indudes information 
relating to the size of memory required to execute 

IS an application. 

9. A method as claimed in any preceding claim in 
which the application information in the applk:atiori 
data tak)le includes a priority value indicating the 

20 relative priority of an application. 

10. A method as claimed in any preceding claim In 
which the application information in the application 
data table includes a service exclusive value indi- 
es eating that an application is exclusive to one or 

more services. 

11. A method as claimed in any preceding daim in 
which the application information in the application 

30 data table includes a flag value concerning the 
action to be taken wKh an applicatk)n upon a 
change of service. 

12. A method as claimed in any preceding daim €is 
35 applied to a digital television system. 

13. A method as claimed in any preceding claim in 
which the digital transport stream conforms to the 
MPEG standard. 

40 

14. A transmission apparatus for use in a method as 
daimed in any of claims 1 to 13 and adapted to 
transmit a transport stream comprising a plurality of 
servk^es together with an application data table 

45 containing information regarding applications 
carded by a plurality of the services witNn tiie trans- 
port stream. 

15. A decoder for use in a method as daimed in any of 
so dairrs 1 to 13 and including an applk:ation data 

table stored in the memory of the decoder and com- 
prising information regarding applications carried 
by a plurality of services within the transport 
stream, the decoder further being adapted to con- 
55 trol the downloading and/or maintenance of such 
applications in dependence on the information con- 
tained within the applkiation data table. 
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